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[57] ABSTRACT 

A system for eliminating unsolicited electronic mail gener- 
ates and stores a user inclusion list including identification 
data for identifying e-mail desired by the user. Data from 
one or more fields of incoming electronic mail messages are 
compared with the identification data stored in the user 
inclusion list. If the electronic mail message data matches 
corresponding identification data from the user inclusion 
list, the e-mail message is marked with a first display code, 
such as "OK." If no match is detected, the system performs 
at least one heuristic process to determine whether the 
electronic mail message may be of interest to the user. If the 
message satisfies one or more criteria as determined by the 
heuristic process and is therefore of potential interest to the 
user, the message is marked with a second display code, 
such as "NEW." If the e-mail message does not satisfy any 
of the heuristic criteria, the e-mail message may be marked 
with a third display code, such as "JUNK." The processed 
e-mail messages are displayed to the user in a display mode 
corresponding to the display codes respectively assigned to 
the messages. 

31 Claims, 7 Drawing Sheets 
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SYSTEM AND METHOD FOR FILTERING 

UNSOLICITED ELECTRONIC MAIL 
MESSAGES USING DATA MATCHING AND 
HEURISTIC PROCESSING 

FIELD OF THE INVENTION 5 

The present invention relates to a method and system for 
filtering electronic mail ("e-mail") sent to one or more users 
via a communications network to eliminate unsolicited 
e-mail from the user's electronic mailbox. The method and 
system according to the present invention sort e-mail mes- 10 
sages by comparing one or more predetermined data fields 
of each e-mail message with data stored in an automatically 
updated database of acceptable addresses and domains. The 
e-mail messages with matching data are forwarded to the 
respective user's mailbox. The e-mail messages without 15 
matching data are sorted using one or more heuristic sorting 
methods and categorized either as "junk," which are not of 
interest to the user, or as "new" which are of potential 
interest to the user. Each message is displayed to the user in 
accordance with its respective status. 20 

BACKGROUND OF THE INVENTION 

The rapid increase in the number of users of electronic 
mail and the low cost of distributing electronic messages via 
the Internet and other electronic communications networks 25 
has made marketing via electronic mail ("e-mail") an attrac- 
tive advertising medium. Consequently, e-mail is now fre- 
quently used as the medium for widespread marketing 
broadcasts of messages to e-mail addresses, commonly 
known as "spam." 30 

Users of electronic mail, however, frequently are not 
eager to have their e-mail boxes filled with unsolicited 
e-mails. Users accessing the Internet through large service 
companies such as America Online® (AOL) or Microsoft 
Network® (MSN) or large businesses such as IBM® and 35 
General Motors® are targeted by e-mail marketers. The 
sending and receiving of unsolicited e-mail messages are 
increasing problems for both online services and corpora- 
tions. Online services object to unsolicited mail because it 
reduces their users* satisfaction of their services, and cor- 40 
porations want to eliminate unsolicited mail because it 
reduces worker productivity. 

There are a number of known methods for filtering 
unsolicited e-mail. Typically, these methods are designed to 
block e-mails from particular e-mail addresses that originate 4 5 
unsolicited e-mail. For example, filtering methods used by 
America On Line® and Prodigy® use an exclusion filter that 
blocks e-mail messages received from addresses that are 
suspected sources of unsolicited e-mail are blocked. 
However, this approach is vulnerable to rapid changes in the 50 
source of unsolicited e-mail. Furthermore, because courts 
have ruled that online services can not automatically block 
e-mail addresses from their members, these services are 
available only if the user requests them. 

Other known e-mail filtering techniques are based upon 55 
an inclusion list, such that e-mail received from any source 
other than one listed in the inclusion list is discarded as junk. 
However, these methods require the user and/or service 
provider continually to update the inclusion list manually. If 
the inclusion list is not updated regularly, the list will 60 
quickly become outdated, resulting in exclusion of desired 
e-mail messages from new sources and continued inclusion 
of undesired e-mail messages from old sources. 

SUMMARY OF THE INVENTION 65 

In view of the drawbacks of the known methods for 
filtering unsolicited e-mail, an object of the present inven- 
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tion is to provide a system and method for eliminating 
unwanted e-mail messages. According to the present 
invention, incoming e-mail messages are filtering using an 
automatically updated inclusion list. E-mail messages 
received from sources other than those on the automatically 
updated inclusion list are not automatically discarded. 
Instead such e-mail messages are further processed using 
one or more heuristic processing techniques to determine 
whether the e-mail is truly junk mail or is instead e-mail 
from a new source which may be of interest to the user. 
Thus, the subject invention makes it possible to eliminate 
virtually all of unsolicited e-mail messages and is not 
vulnerable to changes in the unsolicited e-mail origin 
addresses. The present invention also enables the user to 
receive new e-mail of potential interest to the user even 
though the source of the e-mail is not included in the user's 
inclusion list. Furthermore, because the filtering is per- 
formed based upon parameters defined by the user, the 
invention should not be subject to the court rulings of 
exclusion filters used to date. 

A method for eliminating unsolicited electronic mail 
according to the present invention includes the steps of: 

(a) automatically generating and storing a user inclusion list 
including identification data for identifying e-mail desired 
by the user; 

(b) receiving an electronic mail message; 

(c) comparing data from the received electronic mail mes- 
sage with identification data in the user inclusion list; 

(d) upon identifying a match between the electronic mail 
message data and the identification data, marking the 
e-mail message with a first display code; and 

(e) displaying the electronic mail message marked with the 
first display code to the user, wherein the electronic mail 
marked with the first display code is displayed to the user 
in a first display format. 

The method further includes the following steps: 

(f) upon failing to detect a match between the electronic mail 
message data and the identification data in the user 
inclusion list, performing at least one heuristic process to 
determine whether the electronic mail message may be of 
interest to the user; 

(g) upon identifying the electronic mail as of interest to the 
user, marking it with a second display code; 

(h) displaying the electronic mail marked with the second 
display code to the user; and 

(i) upon failing to identify the electronic mail as of interest 
to the user, marking the electronic mail message with a 
third display code, wherein the e-mail message is dis- 
played to the user. 

A system for eliminating electronic unsolicited mail 
according to the present invention includes an inclusion list 
processor for automatically creating and storing identifica- 
tion data for identifying e-mail desired by the user; an e-mail 
storage unit for storing incoming electronic mail messages; 
an e-mail filter for filtering the stored incoming electronic 
mail messages in accordance with the identification data 
stored in the inclusion list processor; and a user interface for 
displaying the filtered electronic mail messages to a user and 
for enabling the user to modify the identification data stored 
in the inclusion list processor. 

The foregoing and other features, aspects, and advantages 
of the present invention will become more apparent from the 
following detailed description when read in conjunction 
with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 provide a block diagram of the components of a 
user-site software system in accordance with the present 
invention. 
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FIG. 1A provides a block diagram of an alternative 
configuration of the user-site software system shown in FIG. 
1. 

FIG. 2 provides a block diagram of the components of an 
inclusion list processor for use in the system of FIG. 1. 

FIG. 3, 3A provide a block diagram of the components of 
a server-based embodiment of the present invention. 

FIG. 4, 4A provide a process flow chart for a method for 
eliminating undesired unsolicited e-mail according to the 
present invention. 

FIG. 5 provides an example of data stored in a user 
inclusion list. 

FIG. 6 provides an additional process flow chart for a 
method for eliminating undesired unsolicited e-mail accord- 
ing to the present invention. 

DETAILED DESCRIPIION OF THE 
PREFERRED EMBODIMENTS 

The present invention will now be described with refer- 
ence to the accompanying drawings, which are provided as 
illustrative examples of preferred embodiments of the 
present invention. Notably, the present invention may be 
implemented using software, hardware or any combination 
thereof as would be apparent to those of skill in the art. 

As shown in FIG. 1, a preferred embodiment of a user 
terminal software system for eliminating unsolicited e-mail 
in accordance with the present invention includes an inclu- 
sion list manager 102 that creates, stores and automatically 
maintains a user inclusion list. The user inclusion list 
includes all identification data needed to determine the status 
of incoming e-mail messages. As will be described below in 
further detail, the user inclusion list may be created and 
maintained automatically and also modified manually by the 
user. 

The user terminal software system of FIG. 1 further 
includes an e-mail storage database 106 that receives and 
stores incoming e-mail and stores records of outgoing 
e-mail. An e-mail filter 104 filters the incoming e-mail stored 
in store 106 in accordance with the user inclusion list stored 
in database 102. A user interface 108 receives inputs from 
the user and displays e-mail information to the user. The user 
interface 108 may be implemented, for example, using a 
known e-mail software software package, such as 
Netscape® Messager®, Microsoft® Outlook®, Microsoft® 
Exchange®, Lotus® cc: mail®, Lotus Notes®, Novell® 
Groupwise®, Eudora®, or America OnLine®. User inter- 
face 108 may be used, for example, to display a user's 
mailbox, receive and process e-mail messages and inputs 
from the user, manage the user's mailbox, and display 
mailbox management information to enable the user to 
manage the mailbox. 

According to one embodiment of the present invention, 
the e-mail filter 104 filters incoming mail received in the 
user's e-mail store 106 based upon three fields of data 
contained in the incoming e-mail, the "FROM" field, the 
"TO" field and the "SUBJECT" field. Notably, filtering may 
also include the "CC" field and the "BCC" field to filter 
e-mail messages on which the user is listed as a CC or BCC 
recipient rather than a direct recipient. Preferably, the e-mail 
filter 104 compares the "FROM", "TO", "CC", "BCC", and 
"SUBJECT" fields of an incoming e-mail message with the 
corresponding data categories stored in the inclusion list 
manager 102. 

In a preferred embodiment, if the data in any of the fields 
of the incoming e-mail message match data in the corre- 
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sponding data category stored in the inclusion list manager 
102, the e-mail is marked by the filter 104 with a first display 
code indicating the "OK" status of the message. The mark- 
ing of the incoming e-mail may be accomplished using 
known programming techniques as would be know to one of 
skill in the art, for example, by adding an additional field of 
information to the received e-mail format or by altering one 
or more existing e-mail fields to indicate the display status 
of the e-mail. The e-mail message is then displayed in the 
user's inbox by the user interface 108 in accordance with the 
first display code. 

If the e-mail filter 104 does not detect a match between the 
stored inclusion list data and the data from the received 
e-mail message, the incoming e-mail is further processed 
using one or more heuristic processing techniques to deter- 
mine whether the e-mail may be of interest to the user. The 
filtering process and the heuristic processing techniques will 
be described in further detail below. If the e-mail message 
satisfies one or more criteria as determined with the heuristic 
processing, the e-mail message is marked with a second 
display code. If the data in the e-mail message do not match 
the data in the inclusion list and if the message also does not 
satisfy the heuristic processing criteria, then the message is 
marked with a third display code. 

Each e-mail message is thus displayed to the user in 
accordance with its respective display code, thereby indi- 
cating the status of the message to the user. 

FIG. 2 provides a block diagram of an inclusion list 
manager 102 for use in the system of FIG. 1. The inclusion 
list manager 102 includes a list processor 201 and a storage 
unit 202. The storage unit 202 stores the user inclusion list 
as created and maintained by the list processor 201. 

According to one embodiment of the present invention, 
the inclusion list processor 201 automatically creates, stores 
and updates five different categories of data corresponding 
to five different data fields of incoming e-mail messages: 
"TO," "FROM," "CC," "BCC," and "SUBJECT" and other 
user-definable text fields in the header. An example of such 
a list is shown in FIG. 5. 

The "FROM" data stored by the inclusion list processor 
201 is created and maintained as follows. In the preferred 
embodiment depicted in FIG. 2, the list processor 201 
initially creates the user inclusion list by automatically 
gathering acceptable e-mail source addresses from a plural- 
ity of sources 203 through 208. Sources 203 (user's inbox), 
204 (user's outbox), and 205 (user's address book), for 
example, may be stored within the user's e-mail store 106 
and may be accessed through user interface 108. As depicted 
in FIG. 2, source 206 is a database for storing a list of e-mail 
addresses defined by the user. This may include, for 
example, the e-mail addresses displayed by the user's real- 
time awareness and notification system. Such systems gen- 
erate displays of e-mail addresses corresponding to other 
users who are on-line at the same time as the user. This 
functionality may be provided, for example, using programs 
such as AOL's Buddy List®, Excite's® Personal Access 
List®, or AOL's Instant Messenger®. 

Source 206 may be stored on a server (not shown) 
connected to the user site by a communications network (not 
shown). As shown in FIG. 2, sources 207 (user's personal 
manager) and 208 (other programs) are independent soft- 
ware programs stored on the user's computer or a server (not 
shown) attached to the user's computer via a communica- 
tions network (not shown). In the preferred embodiment 
depicted in FIG. 2., when the filtering system according to 
the present invention is first initiated, the list processor 201 
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automatically accesses the e-mail addresses stored in filter as long as those other users include the password in the 

sources 203 through 208, formats them into an inclusion list "SUBJECT" field of their messages. This embodiment also 

(see FIG, 5), and stores them in storage unit 202. Thus, the eliminates unsolicited mail more effectively because the 

user's initial inclusion list is automatically created, filter will pass only those e-mails with specific "SUBJECT" 

In a preferred embodiment, the list processor 201 also 5 field entries, 

automatically updates the inclusion list. In order to insure ^ "SUBJECT* data stored in the user inclusion list may 

that the inclusion list remains current, the list processor 201 be compared to the "SUBJECT" field of the incoming e-mail 

accesses (polls) e-mail address information from the sources mes f K a S e > for sample using a text search, keyword search 

->ni .~ n »^t Pm ,; 0 ^ • . nf H . M1 . _ , . or other search as would be apparent to one of skill in the art. 

203 to 208 at predeterm ned intervals of time such as hourly, M ^ ^ "FROM" category of the inclusion list, the user 

daily, weekly or monthly. The update process may also be io man ^ the V UBJECr , cal t0 add or 

implemented as an inter^pt-dnven proassprompted by one ^ suW wQrds or ^ ^ desired This of 

or more of the sources 203 through 208 The list processor the {is{ alsQ be automaticall d *J t0 

201 compares the e-mail addresses stored in sources 203 to indude Qew subjecl data of newJ ^ e _ mai j m s {a 

208 with those stored m the user inclusion ,ta and adefc new ^ ^ ombox Qmer SOUfces of « SUJB j Ecr data % uch 

e-mail addresses from the sources 203 to 208 to the inclusion 15 u ^ ^ inbox Qf data ^ {q ^ ms 

list In this way, the user inclusion list may be automatically 0Q me ^ compmer may ^ be used tQ Cfeate and 

updated> maintain the "SUBJECT" category of the user inclusion list 

In addition to automatically adding new e-mail source stored by inclusion list processor 102. 

addresses to the inclusion list, the list processor 201 may In addition lo , he aulomalic and manual upda ti ng 0 f the 

also optionally delete old addresses from the inclusion list. user incIusion list described above, new data may optionally 

For example, the list processor 201 may be programmed to be added t0 the user inclusion list ^ inc0 ming e-mail 

delete an e-mail address from the inclusion list when the messages are processed. For example, if a received e-mail 

e-mail address is not stored in the user's address book, message has "SUBJECT" or other user-definable header 

buddy list or personal manager and has not appeared in the field data matching "SUBJECT" or other user-definable 

user's inbox or outbox for a predetermined period of time, header data in the inclusion Hslj the "FROM" and "TO" data 

such as a month. The user may also be prompted to delete from the e . mail message may be automatically added to the 

an inclusion list entry as a result of the user's deletion of an user inclusion lisl by the list processor 201. As another 

entry from the user's inbox, outbox, address book, buddy list example, when a received e-mail message has "TO" field 

or personal manager. The functionality of list processor 201 data matching « T0 » data in the inclusion list, the "FROM" 

may be accomplished using known programming techniques and "SUBJECT" [or subset of "SUBJECT"] or user defin- 

as would be apparent lo one of skill in the art. able header data from the e _ mail message may be automati- 

The user may also manually modify the user inclusion list ca n y a dded to the inclusion list. As a further example, when 

through the user interface 108. The list processor 201 a received e-mail message has "FROM" field data matching 

receives any modification instructions from the user, such as 35 "FROM" data in the inclusion list, the "TO" and "SUB- 

"add e-mail address," "delete e-mail address," or "modify JECT" or user-definable header data may be automatically 

e-mail address," and modifies the stored user inclusion list a dded to the inclusion list. In these and other manners 

accordingly. apparent to users and others of ordinary skill, the inclusion 

The "TO," "CC," and "BCC" inclusion list categories list may be continually and dynamically varied as e-mail 

may be initially set to automatically include the e-mail 40 messages are received and processed, 

address of the user. If so, then any incoming e-mail messages A filtering system according to the present invention may 

having the user's e-mail address in the "TO," "CC" or be implemented at the user terminal either as an integrated 

"BCC" field will be displayed in the user's inbox. This function within a user's e-mail program, such as Netscape 

category of the user inclusion list serves to distinguish Messager, Microsoft Outlook, Microsoft Exchange, Lotus 

e-mail specifically directed to the user from e-mail 45 cc: mail, Lotus Notes, Novell mail, Eudora, or AOL, or as 

addressed to broad catego ries of users. As with the "FROM" a separate user application that interacts with the user's 

category of the inclusion list, the user may manually modify existing e-mail user as would be apparent to one of ordinary 

the "TO," "CC and/or "BCC" categories to add or delete skill in the art. In either embodiment, the e-mail filter 104 

addresses as desired. This category may also be automati- interacts with the e-mail store 106 to access, modify, and 

cally updated to reflect any changes in the user's e-mail 50 categorize e-mail messages as described above, 

address and/or mailing lists to which the user may subscribe. piG. 2A illustrates an alternative preferred embodiment of 

According to a preferred embodiment of the present the present invention in which the e-mail filter 104 interacts 

invention, the "SUBJECT" category of the user inclusion directly with the network e-mail server. The e-mail filter 104 

list may be initially set to automatically include the infor- receives and filters incoming e-mail messages before they 

mation in the "SUBJECT" field of each message in the 55 are stored in e-mail store 106. This embodiment may be 

user's e-mail outbox. Thus, any incoming e-mail messages implemented using a known message communications 

having "SUBJECT" field data matching the "SUBJECT" means, such as Microsoft's Mail API (MAPI) or an Internet 

data of a message in the user's outbox, for example, a reply mail protocol such as Post Office Protocol (POP3), IMAPor 

message, would be displayed in the user's inbox. Simple Mail Transfer Protocol (SMTP). In a preferred user 

According to another preferred embodiment of the present 60 terminal embodiment, the system according to the present 

invention, the "SUBJECT" or other user-definable e-mail invention is implemented as an add-on system to a known 

header category of the inclusion list remains empty until the e-maU software package, for example, using MAPI config- 

user manually enters information for this category or the ured as a network service provider. This embodiment has the 

inclusion list. This embodiment of the present invention advantage of simplifying the implementation of the present 

enables a user to define one or more specific passwords to 65 invention at the user site terminal. 

insure that mail messages sent from individuals with whom FIG. 3 illustrates a server embodiment of the present 

the user wants to communicate are never eliminated by the invention. This embodiment enables filtering to be per- 
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formed at a central location for all users within a network protocol such as POP3, IMAP or SMTP. This embodiment 

such as a local area network (LAN). As depicted in FIG. 3, has the advantage of reducing the data traffic flow on a 

an e-mail server 301 receives and routes e-mail messages to communications link by filtering out unsolicited e-mail 

and from a plurality of users such as A, B, C, and D attached before it is stored at the user site. 

to an electronic data network 300. The e-mail server may 5 The preferred embodiment of a server-based embodiment 

also receive e-mail from other networks 315. The e-mail of the present invention has the advantage of enabling quick 

server 301 includes an e-mail server message store 306 for deployment of the invention because server software can 

receiving and storing all e-mail messages transmitted within generally be updated more quickly than user software. A 

the network 300 and an e-mail filter 304. An inclusion list server-based embodiment also has the advantages of ease of 

processor 302 stores and maintains at least one inclusion list 10 implementation in an environment where there are multiple 

for each e-mail address that is serviced by the e-mail server e ' ma 1 d ^f 5 ' Reducing the wasted bandwidth of sending 

301. For example, in the network configuration depicted in e " mai1 me f 10 ™™ who will not read thern^ 

FIG. 3, the inclusion list processor 302 maintains a separate A r me ' ho f d according to the present invention and 

user inclusion list for each user A, B, C and D. P u erformed ' f °^ ™ m P h > b * lhe . ™l .^teis 104 and 304 

„ . _ , -« shown in FIGS. 1 and 3 respectively will now be described 

Tie operation of the components of the e-ma.l server 301 « in ^ wjlh reference , Q F , GS 4 aQd g 

shown in FIG. 3 is similar to the corresponding components ~ T/ -, A a . . . u . 4 . au 
... . , c i A I, • it FIG. 4 provides a process flowchart illustrating the filter- 
in the user terminal system of FIG. 1. All e-mail received by * r ,! n U lnA A <rnA rV ♦ • 

- M . 4 • . . «a/ T*t. t*u ~>ixa ing steps performed by e-m ail filters 104 and 304. First, in 

server 301 is stored in e-mail store 306. The e -mail filter 304 . am -i • jc .l . i 

/;n ... j •, • j step 401, an e-mail message is received from the network 

filters the stored e-mail messages in accordance with the ./ . 1 * u .u j u j ■ 

. f . . « . « . a . a . i ai t* -1 on either by a user site system such as the system described in 

information stored in the inclusion list processor 302. E-mail m * . . . u . . A 

. , , . , A n ~ , ~ . . />»4 i FIG. 1 or by an e-mail server such as the system described 

addressed to each user A, B, C, and D is separately filtered . ^ i T . . c .u -i 

.... «• j ■ ■ i * i \ , n * in FIG. 3. Upon receipt of an e-mail message, the e-mail 

using the inclusion list stored in inclusion list processor 302 au , i A ^\ j ♦ e t r • a a u r 

- ° . • i ^ i i j • filter (e.g., 104 or 304) retrieves data rrom selected fields or 

for each user respectively. Once the e-mail stored in store . v ? ' 7 , . Atx ~ T 

. ,v au ™a &u j -i ■ the received e-mail message as shown in step 402. In step 

306 is processed by e-mail filter 304, the filtered e-mail is ™ ., & - . , , , r . . j P 

, 4 . . ~r 403, the e-mail filter compares the field data retrieved from 

then forwarded to each user s terminal. 25 » . r . 

the received message with data stored in the corresponding 

In the preferred embodiment of the present invention category of the user inclusion list. In step 410, if the field 

depicted in FIG. 3, the filtering process performed for each data from the rece ived message matches a data entry stored 

user A, B, C, and D by the e-mail filter 304 is the same as m the corresponding category of the inclusion list, the 

that performed by filter 104 in FIG. 1. The filter 304 rece i ve d message is marked with a first display code indi- 

compares the data stored in the "TO," "FROM," "CC," eating that the status of the message is "OK'Mn step 411, the 

"BCC," and "SUBJECT" fields of the incoming e-mail field data from the received message may optionally be 

messages with corresponding categories of data stored in the added to the corresponding categories of data in the user 

inclusion list processor 302. If data in any of these fields of inclusion list 

the incoming e-mail matches data stored in a corresponding M shown \ n pjQ 4A? comp aring step 403 may include a 

field of the inclusion lust processor 302, the incoming e-mail comparison of dala retrieved from the « T0 ,» "FROM" and 

is marked OK and forwarded to the user. If no match is "SUBJECT* fields of the received message. As shown in 

detected, the e-mail filter 304 performs at least one type of st m if tfae «pRQM" field data from the received e-mail 

heuristic processing to determine whether ^the e-mail may be m e docs nQ{ match data in tfac "pROM" 

of interest to the user, and, if not labe s the e-mail message category of the stored inclusion list, the "TO," "CC," and 

accordingly, for example, as JUNK. « BCC „ fidd data ffom thc reccived message ^ compared l0 

In the preferred server embodiment shown in FIG. 3, the the corresponding categories of data stored in the user 

e-mail filter 304 interacts with the e-mail message store 306 inclusion list in step 405. 

that processes the e-mail and performs other known func- ^ uj ustraled m slep 406 of FIG. 4A, if the "TO" field 

tions for a multiplicity of e-mail addresses or accounts. In 45 data from lhe received e . mail messa ge does not match any 

the preferred embodiment, the e-mail store 306 is an data eDtry in lhe <T0 « category of the stored inclusion list, 

improved e-mail server message store that stores additional lhe lext stored in lne "SUBJECT" field data of the received 

information about thc category of each e-mail message. In meS sage is compared to the corresponding category of text 

an alternative preferred embodiment, the status of e-mail data slored in lne uscr inclusion list. If a match is found, the 

messages is handled in a separate database (not shown) 5Q rece ived message is marked with the first display code 

outside the message store 306. indicating that the status of the message is "OK" (step 410). 

As depicted in FIG. 3, the inclusion list processor 302 The "FROM" and "TO" data from the received message 

may store an inclusion list for each e-mail address or, may optionally be added to the corresponding categories of 

alternatively, an inclusion list for each group of e-mail data in the user inclusion list (step 411). 

addresses organized by domain or other group. According to 55 if n0 matches of the "FROM," "TO," "CC," "BCC," or 

another alternative preferred embodiment, each inclusion "SUBJECT" field data are identified in step 403 of FIG. 4 or 

list created and maintained by the inclusion list processor ste ps 404 to 406 of FIG. 4A, in step 412 the e-mail filter 

302 includes an additional data field to identify character- performs one or more heuristic processes to determine 

istics of at least one user account or e-mail address. This whether the received e-mail message meets certain criteria 

embodiment has the advantage of providing centralized 60 suggesting that the message may be of interest to the user, 

management of account information for electronic mes- if the e-mail message meets one or more of the heuristic 

sa g es - criteria, in step 413 the e-mail is marked with a second 

FIG. 3A illustrates an alternative preferred embodiment in display code indicating that the status of the message is 

which the e-mail filter receives and filters incoming e-mail "NEW." The "lTO,""FROM" and "SUBJECT' field data 

messages before they are stored in e-mail store 306. This 65 from the e-mail message may optionally be added to the user 

embodiment may be implemented using a known message inclusion list by the inclusion list processor (e.g., 102 or 

communications means, such as MAPI or an Internet mail 302) as show in step 414. 
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As shown in step 420, if the e-mail message data does not 
meet any of the heuristic criteria tested in step 412, the 
message is marked with a third display code indicating that 
the e-mail has a "JUNK" status. In one embodiment of the 
present invention, the e-mail message is not displayed to the 
user (step 421) and ultimately discarded by the system (step 
422). 

E-mail messages are displayed to the user in a display 
format determined by their display codes (step 415). For 
example, "OK," "NEW" and "JUNK" messages may be 
displayed in different colors to indicate their different status. 
Other possible display modes include: a) no modification b) 
changing the subject line to reflect the status such as 
changing "Make money FAST!" to "JUNK: Make money 
FAST!"; c) changing font or appearance of the message 
subject line to reflect its status; or d) placing the message in 15 
a folder based on its status (or other modes as are known in 
the art). The present invention contemplates numerous dis- 
play options for the different types of e-mail messages which 
arc apparent to those of skill in the art. 

Notably, while the embodiments of the present invention 20 
described above describe e-mail processing in which there 
are three categories of e-mail messages, the use of additional 
categories are envisioned to fall within the scope of the 
present invention. These may be defined as necessary by 
defining additional processing steps. For example, e-mail 25 
messages from certain sources may be marked with a 
display code indicating that they have a "PRIORITY" status. 
Different e-mail display colors or folders may be defined 
based upon the identify of the sender, or the subject matter 
of the messages. Such modifications are intended to fall 30 
within the scope of the present invention. 

A preferred embodiment of the heuristic processing 
described in step 412 of FIG. 4 will now be described in 
additional detail. Heuristic processing according to the 
present invention involves evaluating the message with one 35 
or more of the following rules. The "FROM" field matches 
a "TO" entry in the user inclusion list; 

1. The "FROM" field has a domain that matches an Internet 
domain of one or more entries in the "FROM" category of 
the user inclusion list; 

2. The "FROM" field has a domain that matches one of a 
pre-defined list of domains that are assured to be junk-free 
such as corporations or government organizations. 

3. The "FROM" field has a domain that matches one of a 
multiplicity of domains that are input by the user. 
If any of the tests result in a "true" value, the message is 

marked "NEW." Otherwise, it is marked as "JUNK." 

An alternative embodiment to the heuristics includes a 
user-selectable option to use any of these rules. Another 
alternative embodiment reduces or adds these rules to either 
reduced the complexity of implementation or improve the 
quality of the filtering. Other heuristic filtering rules may 
also be defined to assist the e-mail filter in identifying 
e-mails that do not match the stored categories of the user 
inclusion list but are nonetheless of interest to the user. 

The filtering method according to the present invention 
may also be implemented in combination with one or more 
known exclusion-based filtering methods. A preferred 
embodiment of such a combination method is illustrated in 



40 
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In a preferred implementation of a combination of the 
filtering method according to the present invention with an 
exclusion-based filtering step, filtering of incoming e-mail 
messages is performed in the following sequence. First, the 
messages are filtered using inclusion list data defined by the 
user. Second, the messages are filtered using exclusion list 
data defined by the user. Third, the messages are filtered 
using inclusion list data automatically created by the system 
as described above and/or predefined inclusion list data. 
Fourth, the messages are filtered using predefined exclusion 
list data. 

While the present invention has been particularly 
described with reference to the preferred embodiments, it 
should be readily apparent to those of ordinary skill in the art 
that changes and modifications in form and details may be 
made without departing from the spirit and scope of the 
invention. It is intended that the appended claims include 
such changes and modifications. 

I claim: 

1. A method for filtering electronic mail addressed to a 
user, comprising the steps of: 

storing a user inclusion list including identification data 
for identifying e-mail desired by the user; 

receiving an electronic mail message; 

comparing data from said received electronic mail mes- 
sage with said identification data; 

upon identifying a match between said electronic mail 
message data and said identification data, marking said 
electronic mail with a first display code; 

displaying in a first display format said electronic mail 
message marked with the first display code to the user; 

upon failing to detect a match between said electronic 
mail message data and said identification data, per- 
forming at least one heuristic process to determine 
whether said electronic mail message may be of interest 
to the user; 

upon identifying an electronic mail message of interest to 
the user, marking said electronic mail with a second 
display code; 

displaying said electronic mail message marked with said 
second display code to the user in a second display 
format; 

upon failing to identify an electronic mail message of 
interest to the user, marking the electronic mail mes- 
sage with a third display code; and 

displaying said electronic mail message marked with said 
third display code to the user in a third display format. 

2. A method according to claim 1, wherein said inclusion 
list is created and updated based upon e-mail message data 
stored in the user's e-mail inbox. 

3. A method according to claim 1, wherein said inclusion 
list is created and updated based upon e-mail message data 
stored in the user's e-mail outbox. 

4. A method according to claim 1, wherein said inclusion 
list is created and updated based upon e-mail message data 
stored in the user's e-mail address book. 

5. A method according to claim 1, wherein said inclusion 
list is created and updated in respoase to e-mail message 



FIG. 6 and includes an additional filtering step 650 in which 60 data stored in the user's personal manager program. 



selected data fields of the received e-mail message are 
compared to corresponding categories in a stored exclusion 
list (for example, stored in inclusion list processor 104 or 
304). In the preferred embodiment, if any matches are 
detected, the e-mail message is automatically marked 
"JUNK." The remainder of the method steps shown in FIG. 
6. correspond to similarly numbered steps in FIG. 4. 



65 



6. A method according to claim 1, wherein said identifi- 
cation data includes a plurality of categories of data corre- 
sponding to selected fields of e-mail messages received by 
the user. 

7. A method according to claim 6, wherein said electronic 
mail data is data stored in selected fields of said received 
electronic mail message. 
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8. A method according to claim 1, wherein said first (e) upon identifying an electronic mail message of 
display code indicates that said electronic mail message has interest to the user, marking said electronic mail 
a first status, said second display code indicates that said message with a second display code; and 
electronic mail message has a second status, and said third (f) transmitting said electronic mail message marked 
display code indicates said electronic mail message has a 5 with said second display code to said user interface, 
third status. 15. A system according to claim 14, wherein said user 

9. A method according to claim 1, further comprising the interface further enables the user to modify said identifica- 
step of varying said inclusion list in response to data from tion data stored in said inclusion list processor, 
received electronic mail messages marked with said first or 16. A system according to claim 14, wherein said filtering 
second display code. further comprises the steps of: 

10. A method according to claim 1, wherein said at least upon failing to identify an electronic mail of interest to the 
one heuristic process includes at least one of the following user, marking the electronic mail message with a third 
tests: display code; and 

(a) a test to determine whether a first field of said received transmitting said electronic mail message marked with 
electronic mail message matches a corresponding entry said third display code to said user interface. 

in said user inclusion list; 1? Jhe syslem according l0 claim H wherein aid 

(b) a test to determine whether said first field of said system is implemented within a user terminal. 

received electronic mail message has a domain that 18 ^ tem according t0 claim 14 wherein ^ 
matches an Internet domain of one or more entries in 



system is implemented within a central network server. 



the corresponding category of said user inclusion list; 19 A system according l0 claim 14> wherein said indu . 

(c) a test to determine whether the first field of said sion Hst ^ created and updated based upon e-mail message 
received electronic mail message has a domain that data stored m the user > s e . mail in5ox 

matches one of a pre-defined list of domains; or 2 0. A system according to claim 14, wherein said inclu- 

(d) a test to determine whether a second field of said s j on \\ sl \& created and updated based upon e-mail message 
received electronic mail message matches a second ^ dala stor ed in the user's e-mail outbox. 

entry in said user inclusion list. 21. A system according to claim 14, wherein said inclu- 

11. A method according to claim 1, further comprising the s j on ^ {$ created and updated based upon e-mail message 
step of filtering said electronic mail message using an data stored j n t he user's e-mail address book, 
exclusion list. 22. A system according to claim 14, wherein said inclu- 

12. A method according to claim 11, wherein, when the 3Q s j on list is created and updated in response to e-mail 
data from said electronic mail message matches data stored message data stored in the user's personal manager program, 
in said exclusion list, said electronic mail message is marked 2 3. A system according to claim 14, wherein said identi- 
with said third display code and displayed to the user in said fixation data includes a plurality of categories of data 
third display mode. corresponding selected fields of incoming e-mail messages. 

13. A method according to claim 1, wherein said inclusion 35 24. A system according to claim 23, wherein said elec- 
list is created and updated based upon e-mail message data tron j c m ail data is data stored in said selected fields of said 
stored in the user's real-time awareness and notification received electronic mail message. 

system. 25. A system according to claim 16, wherein said first 

14. A system for eliminating unsolicited electronic mail, display code indicates that said electronic mail message has 
comprising: 4o a fi^ status, said second display code indicates that said 

an inclusion list processor for storing identification data electronic mail message has a second status, and said third 

for identifying e-mail desired by the user; display code indicates that said electronic mail message has 

an e-mail storage unit for storing incoming electronic mail a third status. 

messages; 26. A system according to claim 14, wherein said inclu- 

an e-mail filter for filtering said stored incoming elec- 45 sion list processor varies said inclusion list in response to 

tronic mail messages in accordance with said identifi- data from received electronic mail messages marked with 

cation data stored in said inclusion list processor and said first or second display code. 

for marking each of said electronic mail messages with 27. A system according to claim 14, wherein said at least 

one of a plurality of display codes to indicate a status one heuristic process includes one or more of the following 

of each of said messages; and 50 tests: 

a user interface for displaying said'filtered electronic mail (a) a test to determine whether a first field of said received 

messages to a user in accordance with said display electronic mail message matches a corresponding entry 

codes; in said user inclusion list; 

wherein said filtering performed by said e-mail filter (b) a test to determine whether said first field of said 

includes the steps of 55 received electronic mail message has a domain that 

(a) comparing data from said incoming electronic mail matches an Internet domain of one or more entries in 
messages with said identification data; the corresponding category of said user inclusion list; 

(b) upon identifying a match between said electronic or 

mail message data and said identification data, mark- (c) a test to determine whether said first field of said 

ing said electronic mail with a first display code; 60 received electronic mail message has a domain that 

(c) transmitting said electronic mail message marked matches one of a pre-defined list of domains. 

with the first display code to said user interface; 28. A system according to claim 14, further comprising 

(d) upon failing to detect a match between said elec- the step of filtering said electronic mail message using an 
tronic mail message data and said identification data, exclusion list, wherein, when the data from said electronic 
performing at least one heuristic process to deter- 65 mail message matches data stored in said exclusion list, said 
mine whether said electronic mail message may be electronic mail message is marked with said third display 
of interest to the user; code and displayed to the user in said third display mode. 
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29. A system according to claim 14, wherein said inclu- 
sion list is created and updated based upon e-mail message 
data stored in the user's real-time awareness and notification 
system. 

30. A method for filtering electronic mail addressed to a 5 
user, comprising the steps of: 

storing a user inclusion list including identification data 
for identifying e-mail desired by the user; 

receiving an electronic mail message; 

comparing data from said received electronic mail mes- 
sage with said identification data; 

upon identifying a match between said electronic mail 
message data and said identification data, marking said 
electronic mail with a first display code; 15 

displaying in a first display format said electronic mail 
message marked with the first display code to the user; 

upon failing to detect a match between said electronic 
mail message data and said identification data, per- 
forming at least one heuristic process to determine 20 
whether said electronic mail message may be of interest 
to the user; 

upon identifying an electronic mail message of interest to 
the user, marking said electronic mail with a second 
display code; 



14 



displaying said electronic mail message marked with said 
second display code to the user in a second display 
format; and 

upon failing to identify an electronic mail message of 
interest to the user, marking the electronic mail mes- 
sage with a third display code such that said electronic 
mail message is not displayed to the user. 
31. A method according to claim 30, wherein said at least 
one heuristic process includes at least one of the following 
tests: 

(a) a test to determine whether a first field of said received 
electronic mail message matches a corresponding entry 
in said user inclusion list; 

(b) a test to determine whether said first field of said 
received electronic mail message has a domain that 
matches an Internet domain of one or more entries in 
the corresponding category of said user inclusion list; 

(c) a test to determine whether the first field of said 
received electronic mail message has a domain that 
matches one of a pre-defined fist of domains; or 

(d) a test to determine whether a second field of said 
received electronic mail message matches a second 
entry in said user inclusion list. 
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A method in a data processing system for managing multiple 
identities for a single user. In a preferred embodiment, a 
request for content from a database is received at a server. 
Responsive to a determination that retrieval of the content 
from the database requires providing the database with user 
information, the user's database identity is retrieved from a 
library of database identities. The retrieved user identity 
information is then inserted into the request and the request 
is forwarded to the database. 
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METHOD TO PROVIDE GLOBAL SIGN-ON 
FOR ODBC-BASED DATABASE 
APPLICATIONS 

CROSS REFERENCE TO RELATED 
APPLICATION 

The present application is related to copending U.S. 
patent application Ser. No. 09/442,694 (entitled "Flexible 
Encryption Scheme for GSO Target Passwords") filed even 
date herewith. The above mentioned patent applications are 
assigned to the assignee of the present invention. The 
content of the cross referenced copending application is 
hereby incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates to the field of computer 
software and, more particularly, to methods and apparatus to 
manage multiple user identities such that the user need only 
maintain a single user identity. 

2. Description of Related Art 

As computers have infiltrated society over the past several 
decades and become more important in all aspects of mod- 
ern life, more and more confidential information has been 
stored on computer databases. However, computers and 
networks such as the Internet allow multitudes of users to 
access databases. Many times multiple databases may be 
accessed via the same network, but not all users on the 
network need or should have access to every database. 
Therefore, security devices have been implemented to pre- 
vent unauthorized access to a database. 

One method of preventing unauthorized access is to 
require the user to provide user identification information to 
verify that that user is entitled to the information contained 
in the database. Thus, many database applications require a 
user to provide identification information, such as a user ID 
and password, in order to access a protected database. These 
applications may have this information fixed within the 
application (i.e., "hard coded"), the application may be 
configured with the information, or, in some cases, the 
application may prompt the user for this information at run 
time. 

However, databases are not the only computer resources 
requiring a user to provide identifying information. Other 
resources such as servers and networks may also require 
users to provide identifying information. Because different 
resources have different security requirements and because 
some resources assign identities rather than allowing a user 
to choose, many users may have multiple identities depend- 
ing on the particular resource that they are accessing. The 
database identity is yet another one that the user must 
maintain. 

Global Sign-on (GSO) technology attempts to manage 
this set of multiple identities on behalf of a user so that the 
user only needs to maintain a single user identity. The user 
then allows the GSO to manage the other identities auto- 
matically whenever the user attempts to access a particular 
protected resource. 

Current versions of GSO use a product technology 
referred to as Open Horizon to provide a single sign-on 
capability for databases. Open Horizon forwards all requests 
through a DCE client RPC mechanism to an Open Horizon 
server. The actual database request is then issued by the 
Open Horizon server. This technique requires a DCE client 
to be installed and configured on the client machine as well 
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as the Open Horizon server to be installed and configured on 
the database server machine. However, it is desirable to have 
a global sign-on system that does not require any additional 
special client software to be installed and configured on the 
5 client machine. It is also desirable to have a global sign-on 
system that does not require an additional server. 

SUMMARY OF THE INVENTION 

The present invention provides a method in a data pro- 
cessing system for managing multiple identities for a single 
user. In a preferred embodiment, a request for content from 
a database, a service, or an application and a first user 
identity entered by a user is received at a database server. 
Responsive to a determination that retrieval of the content 
from the database requires providing the database with user 
information, the user's database identity or other informa- 
tion associated with the database is retrieved from a library 
of database identities on the GSO server. The retrieved user 
2Q identity information is then inserted into the request and the 
request is forwarded to the database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 
25 are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further objec- 
tives and advantages thereof, will best be understood by 
reference to the following detailed description of an illus- 
trative embodiment when read in conjunction with the 
30 accompanying drawings, wherein: 

FIG. 1 depicts a pictorial representation of a distributed 
data processing system in which the present invention may 
be implemented; 

FIG. 2 depicts a block diagram of a data processing 
35 system which may be implemented as a server in accordance 
with the present invention; 

FIG. 3 depicts a block diagram of a data processing 
system in which the present invention may be implemented; 
40 FIG. 4 depicts a block diagram illustrating a prior art 
ODBC architecture; 

FIG. 5 depicts a block diagram illustrating a software 
architecture in which the present invention may be imple- 
mented; and 

45 FIG. 6 depicts a flowchart illustrating the processes of the 
present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

50 

With reference now to the figures, and in particular with 
reference to FIG. 1, a pictorial representation of a distributed 
data processing system is depicted in which the present 
invention may be implemented. 

55 Distributed data processing system 100 is a network of 
computers in which the present invention may be imple- 
mented. Distributed data processing system 100 contains 
network 102, which is the medium used to provide commu- 
nications links between various devices and computers 

60 connected within distributed data processing system 100. 
Network 102 may include permanent connections, such as 
wire or fiber optic cables, or temporary connections made 
through telephone connections. 

In the depicted example, server 104 is connected to 

65 network 102, along with storage unit 106. In addition, clients 
108, 110 and 112 are also connected to network 102. These 
clients, 108, 110 and 112, may be, for example, personal 
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computers or network computers. For purposes of this 
application, a network computer is any computer coupled to 
a network which receives a program or other application 
from another computer coupled to the network. In the 
depicted example, server 104 provides data, such as boot 
files, operating system images and applications, to clients 
108-112. Clients 108, 110 and 112 are clients to server 104. 
Distributed data processing system 100 may include addi- 
tional servers, clients, and other devices not shown. Distrib- 
uted data processing system 100 also includes printers 114, 
116 and 118. A client, such as client 110, may print directly 
to printer 114. Clients such as client 108 and client 112 do 
not have directly attached printers. These clients may print 
to printer 116, which is attached to server 104, or to printer 
118, which is a network printer that does not require 
connection to a computer for printing documents. Client 
110, alternatively, may print to printer 116 or printer 118, 
depending on the printer type and the document require- 
ments. 

In the depicted example, distributed data processing sys- 
tem 100 is the Internet, with network 102 representing a 
worldwide collection of networks and gateways that use the 
TCP/IP suite of protocols to communicate with one another. 
At the heart of the Internet is a backbone of high-speed data 
communication lines between major nodes or host comput- 
ers consisting of thousands of commercial, government, 
education, and other computer systems that route data and 
messages. Of course, distributed data processing system 100 
also may be implemented as a number of different types of 
networks such as, for example, an intranet or a local area 
network. 

FIG. 1 is intended as an example and not as an architec- 
tural limitation for the processes of the present invention. 

Referring to FIG. 2, a block diagram of a data processing 
system which may be implemented as a server, such as 
server 104 in FIG. 1, is depicted in accordance with the 
present invention. Data processing system 200 may be a 
symmetric multiprocessor (SMP) system including a plural- 
ity of processors 202 and 204 connected to system bus 206. 
Alternatively, a single processor system may be employed. 
Also connected to system bus 206 is memory controller/ 
cache 208, which provides an interface to local memory 209. 
I/O bus bridge 210 is connected to system bus 206 and 
provides an interface to I/O bus 212. Memory controller/ 
cache 208 and I/O bus bridge 210 may be integrated as 
depicted. 

Peripheral component interconnect (PCI) bus bridge 214 
connected to I/O bus 212 provides an interface to PCI local 
bus 216. A number of modems 218-220 may be connected 
to PCI bus 216. Typical PCI bus implementations will 
support four PCI expansion slots or add-in connectors. 
Communications links to network computers 108-112 in 
FIG. 1 may be provided through modem 218 and network 
adapter 220 connected to PCI local bus 216 through add-in 
boards. 

Additional PCI bus bridges 222 and 224 provide inter- 
faces for additional PCI buses 226 and 228, from which 
additional modems or network adapters may be supported. 
In this manner, server 200 allows connections to multiple 
network computers. A memory mapped graphics adapter 
230 and hard disk 232 may also be connected to I/O bus 212 
as depicted, either directly or indirectly. 

Those of ordinary skill in the art will appreciate that the 
hardware depicted in FIG. 2 may vary. For example, other 
peripheral devices, such as optical disk drives and the like, 
also may be used in addition to or in place of the hardware 
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depicted. The depicted example is not meant to imply 
architectural limitations with respect to the present inven- 
tion. 

The data processing system depicted in FIG. 2 may be, for 
5 example, an Intel system running a Windows NT operating 
system. 

With reference now to FIG. 3, a block diagram of a data 
processing system in which the present invention may be 
implemented is illustrated. Data processing system 300 is an 

10 example of a client computer. Data processing system 300 
employs a peripheral component interconnect (PCI) local 
bus architecture. Although the depicted example employs a 
PCI bus, other bus architectures, such as Micro Channel and 
ISA, may be used. Processor 302 and main memory 304 are 

15 connected to PCI local bus 306 through PCI bridge 308. PCI 
bridge 308 may also include an integrated memory control- 
ler and cache memory for processor 302. Additional con- 
nections to PCI local bus 306 may be made through direct 
component interconnection or through add-in boards. In the 

20 depicted example, local area network (LAN) adapter 310, 
SCSI host bus adapter 312, and expansion bus interface 314 
are connected to PCI local bus 306 by direct component 
connection. In contrast, audio adapter 316, graphics adapter 
318, and audio/video adapter (A/V) 319 are connected to 

25 PCI local bus 306 by add -in boards inserted into expansion 
slots. Expansion bus interface 314 provides a connection for 
a keyboard and mouse adapter 320, modem 322, and addi- 
tional memory 324. In the depicted example, SCSI host bus 
adapter 312 provides a connection for hard disk drive 326, 

30 tape drive 328, CD-ROM drive 330, and digital video disc 
read only memory drive (DVD-ROM) 332. Typical PCI 
local bus implementations will support three or four PCI 
expansion slots or add-in connectors. 

35 An operating system runs on processor 302 and is used to 
coordinate and provide control of various components 
within data processing system 300 in FIG. 3. The operating 
system may be a commercially available operating system, 
such as OS/2, which is available from International Business 

40 Machines Corporation. "OS/2" is a trademark of Interna- 
tional Business Machines Corporation. An object oriented 
programming system, such as Java, may run in conjunction 
with the operating system, providing calls to the operating 
system from Java programs or applications executing on 

45 data processing system 300. Instructions for the operating 
system, the object-oriented operating system, and applica- 
tions or programs are located on a storage device, such as 
hard disk drive 326, and may be loaded into main memory 
304 for execution by processor 302. 

50 Those of ordinary skill in the art will appreciate that the 
hardware in FIG. 3 may vary depending on the implemen- 
tation. For example, other peripheral devices, such as optical 
disk drives and the like, may be used in addition to or in 
place of the hardware depicted in FIG. 3. The depicted 

55 example is not meant to imply architectural limitations with 
respect to the present invention. For example, the processes 
of the present invention may be applied to multiprocessor 
data processing systems. 
Turning now to FIG. 4, a block diagram illustrating a prior 

60 art Open Database Connectivity (ODBC) architecture is 
depicted. ODBC architecture provides an abstraction called 
a data source that encapsulates a server, database name, 
schema, network library, and other information for linking a 
client application with data. ODBC supports transaction 

65 commit and rollback, asynchronous processing, an option to 
cancel a query, stored procedures, primary and foreign keys, 
and five levels of transaction isolation. 
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A database application 402, which may reside on a client 
such as client 300, is connected through a network, such as 
network 100, to ODBC Driver Manager Dynamic Link 
Library (DLL) 406 via ODBC Application Programming 
Interface (API) 404. ODBC Driver Manager DLL 406 sits at 
a layer above Loadable Drivers 410 and 412. ODBC Driver 
Manager DLL 406 loads and unloads drivers 410 and 412, 
performs status checking, and manages multiple connections 
between applications and data sources. Loadable Drivers 
410 and 412 may be single- or multiple-tier drivers. Single- 
tier drivers sit directly above a data source and process 
ODBC calls and Structure Query Language (SQL) state- 
ments. Multiple-tier drivers process the function calls and 
pass the SQL request to a server for processing. ODBC 
Driver Manager DLL 406 processes some ODBC calls 
without calling a driver. 

ODBC Driver Manager DLL 406 processes the function 
calls from database application 402 and directs them to the 
appropriate one of loadable drivers 410 and 412 via ODBC 
Driver API 408. Loadable drivers 410 and 412 map the 
ODBC functions into calls to a library of proprietary func- 
tions contained in database proprietary protocols database 
414. 

In implementing a call to a database under this system, a 
user must enter user identification information for each 
database, application, or service that requires this informa- 
tion in order to process a request. Often, the user identifi- 
cation information is different for each entity, thus, a user 
must remember and enter multiple sets of user identification 
information during a computing session. 

Referring now to FIG. 5, a block diagram illustrating a 
software architecture in which the present invention may be 
implemented is depicted. By using this software 
architecture, a user may retrieve documents, applications, 
and other services by using a single main user identity or 
"logon". The user is not require to remember or enter any 
other user identities that may be required to access any of the 
multiple applications or databases that utilize different user 
identities than the main user identity. Such other identities 
are stored, retrieved and sent to the appropriate objects at 
appropriate times automatically using the method and sys- 
tem of the present invention. 

In a preferred embodiment of the present invention, a 
Global Sign-on (GSO) database interface DLL 506 is placed 
between the Open Database Connectivity (ODBC) Applica- 
tion Program Interface (API) dynamic link library (DLL) 
512 and database application 502. GSO database interface 
DLL 512 is a shared library that database application 502 
uses to process ODBC requests. An ODBC API is an 
application programming interface that can operate with 
heterogeneous databases without requiring source code 
changes. Typically, database application 502 will be located 
on a client machine such as data processing system 300 
which will be connected to GSO database interface DLL 506 
via ODBC API 504 by way of a network such as network 
100. GSO database interface DLL 506 is typically located on 
the same client machine as database application 502. 
Alternatively, GSO database interface DLL 506 could be 
located on a separate server using network sharing 
capability, but this is less typical. 

When GSO database interface DLL 506 receives an API 
request from database application 502 via ODBC API 504, 
which requires a user identity, GSO database interface DLL 
506 accesses GSO database 508 to retrieve the user's 
database identity and inserts it into the database request. 
GSO database interface DLL 506 forwards the database 
request to ODBC Driver Manager DLL 512 through ODBC 
API 510. 
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For normal API requests which do not require a user's 
identity, GSO database interface DLL 506 forwards these 
requests to ODBC Driver Manager DLL 512 unchanged. 
Results from ODBC Driver Manager DLL 512 are returned 
5 to database application 502 normally. In this manner, GSO 
database interface DLL is transparent to database applica- 
tion 502 and yet the user's identity is automatically filled in 
on behalf of the user whenever the user executes a database 
application. 

30 ODBC Driver Manager DLL 512 fields the database 
request (or call) from database application 502. ODBC 
Driver Manager DLL 512 sits at a layer above loadable 
drivers 516, 518 and loads and unloads drivers 516, 518 
through ODBC Driver API 514, performs status checking, 

15 and manages multiple connections between applications and 
data sources. Loadable drivers 516, 518 may be single-or 
multiple -tier drivers. Single tier drivers sit directly above a 
data source and process ODBC calls and the structured 
query language (SQL) statements. Multiple-tier drivers pro- 

20 cess the function calls and pass the SQL request to a server 
for processing. Driver Manager 512 fields and processes 
some ODBC calls without calling a driver. 

In either scenario (single- or multiple-tier), ODBC Driver 
Manager DLL 512 processes the function calls of database 

25 application 502 and directs them to the appropriate one of 
loadable drivers 516, 518. Loadable drivers 516, 518 map 
the ODBC functions into calls to a library of proprietary 
functions or database proprietary protocols 520. Database 
522 receives the request, retrieves the appropriate content 

30 and sends it back to database application 502. 

GSO database interface DLL 506 provides an identical set 
of APIs as ODBC Driver Manager DLL 512 so that database 
application 502 works normally. The APIs provided by GSO 

35 database interface DLL 506 have the same signature and 
ordinals. GSO database interface DLL 506 dynamically 
loads the "real" ODBC API DLL 512 so that its use is 
completely transparent to database application 502. GSO 
database interface DLL 506 has the same name as ODBC 

40 DLL 512. Database application 502 can continue to use 
either run time linking or load time linking to access GSO 
database interface DLL 506. When GSO database interface 
DLL 506 is installed and configured, it ensures that the 
operating system will resolve links to the ODBC DLL 512 

45 to it first. It does this by updating PATH to point to GSO 
database interface DLL 506 first, before the real ODBC DLL 
512 routine or by moving the ODBC DLL 512 to another 
location. GSO database interface DLL 506 is also configured 
to know where the "real" ODBC DLL 512 is located so that 

50 it can load it at run time. 

Turning now to FIG. 6, a flowchart illustrating the pro- 
cesses of the present invention is depicted. To start, an 
application requests content from a database (step 602). The 
GSO database interface DLL intercepts the request and 

55 determines whether the request requires a user identity to 
access the information in the database (step 604). If the user 
identity is required to access the information in the database, 
then the GSO database interface DLL retrieves the identity 
information from the GSO database of user identities (step 

60 606) and inserts this user identity into the request (step 608). 
Next, the GSO database interface DLL forwards the request 
to the ODBC Driver Manager DLL (step 610). The database 
containing the requested information is accessed and the 
data retrieved (step 612). The requested data is then returned 

65 to the requesting application (step 614). 

If the request does not require a user identity to access 
information in the database, then the request is forwarded 
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unmodified to the ODBC Driver Manager DLL (step 610), 
which then accesses the database and retrieves the requested 
data (step 612). The requested data is then returned to the 
requesting application (step 614). 

Although the present invention has been described pri- 5 
marily with reference to database applications that utilize the 
Open Database Connectivity (ODBC) database API to 
access the database, the same technique could be used for 
any API that an application uses to access a database, such 
as, for example, the Java JDBC interface. 10 

It is important to note that while the present invention has 
been described in the context of a fully functioning data 
processing system, those of ordinary skill in the art will 
appreciate that the processes of the present invention are 
capable of being distributed in the form of a computer 15 
readable medium of instructions and a variety of forms and 
that the present invention applies equally regardless of the 
particular type of signal bearing media actually used to carry 
out the distribution. Examples of computer readable media 
include recordable-type media such a floppy disc, a hard 20 
disk drive, a RAM, and CD-ROMs and transmission-type 
media such as digital and analog communications links. 

The description of the present invention has been pre- 
sented for purposes of illustration and description, but is not 25 
intended to be exhaustive or limited to the invention in the 
form disclosed. Many modifications and variations will be 
apparent to those of ordinary skill in the art. The embodi- 
ment was chosen and described in order to best explain the 
principles of the invention, the practical application, and to 3Q 
enable others of ordinary skill in the art to understand the 
invention for various embodiments with various modifica- 
tions as are suited to the particular use contemplated. 

What is claimed is: 

1. A method in a data processing system for managing 35 
multiple identities for a user, the steps comprising: 

receiving a request for content from a database; 

responsive to a determination that retrieval of said content 
from said database requires providing said database 
with user identification information, retrieving a data- 40 
base identity from a plurality of database identities, 
wherein the retrieved database identity corresponds to 
the user; 

inserting the retrieved database identity into said request; 
retrieving said requested content from said database; and 45 
sending said requested content to a requesting client. 

2. The method as recited in claim 1, wherein the retrieved 
database identity comprises a user ID. 

3. The method as recited in claim 1, wherein the retrieved 5Q 
database identity comprises a password. 

4. The method as recited in claim 1, wherein said retriev- 
ing step and said inserting step is performed by a global 
sign-on database interface dynamic link library. 

5. The method as recited in claim 1, further comprising: 55 
responsive to a determination that user identification 

information is not necessary to retrieve said content, 
forwarding said request to said database unmodified. 

6. A method in a data processing system for managing 
multiple identities for a user, the steps comprising: 6Q 

receiving a request for content from a database; 

responsive to a determination that retrieval of said content 
from said database requires providing said database 
with user identification information, retrieving a data- 
base identity from a plurality of database identities, 65 
wherein the retrieved database identity corresponds to 
the user; and 
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inserting the retrieved database identity into said request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is an open data- 
base connectivity based application. 

7. A method in a data processing system for managing 
multiple identities for a user, the steps comprising: 

receiving a request for content from a database; 

responsive to a determination that retrieval of said content 
from said database requires providing said database 
with user identification information, retrieving a data- 
base identity from a plurality of database identities, 
wherein the retrieved database identity corresponds to 
the user; and 

inserting the retrieved database identity into said request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is a JAVA data- 
base connectivity based application. 

8. A computer program product on a computer useable 
medium, for use in a data processing system for managing 
multiple identities for a single user, the computer program 
product comprising: 

first instructions for receiving a request for content from 
a database; 

second instructions, responsive to a determination that 
retrieval of said content from said database requires 
providing said database with user identification 
information, for retrieving a database identity from a 
plurality of database identities, wherein the retrieved 
database identity corresponds to the user; 

third instructions for inserting the retrieved database 
identity into said request; 

fourth instructions for retrieving said requested content 
from said database; and 

fifth instructions for sending said requested content to a 
requesting client. 

9. The computer program product as recited in claim 8, 
wherein the retrieved database identity comprises a user ID. 

10. The computer program product as recited in claim 8, 
wherein the retrieved database identity comprises a pass- 
word. 

11. The computer program product as recited in claim 8, 
wherein said retrieving step and said inserting step is per- 
formed by a global sign-on database interface dynamic link 
library. 

12. The computer program product as recited in claim 8, 
further comprising: 

responsive to a determination that user identification 
information is not necessary to retrieve said content, 
forwarding said request to said database unmodified. 

13. A computer program product on a computer useable 
medium, for use in a data processing system for managing 
multiple identities for a single user, the computer program 
product comprising: 

first instructions for receiving a request for content from 
a database; 

second instructions, responsive to a determination that 
retrieval of said content from said database requires 
providing said database with user identification 
information, for retrieving a database identity from a 
plurality of database identities, wherein the retrieved 
database identity corresponds to the user; and 

third instructions for inserting the retrieved database 
identity into said request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is an open data- 
base connectivity based application. 
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14. A computer program product on a computer useable 
medium, for use in a data processing system for managing 
multiple identities for a single user, the computer program 
product comprising: 

first instructions for receiving a request for content from 
a database; 

second instructions, responsive to a determination that 
retrieval of said content from said database requires 
providing said database with user identification 
information, for retrieving a database identity from a 
plurality of database identities, wherein the retrieved 
database identity corresponds to the user; and 

third instructions for inserting the retrieved database 
identity into said request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is a JAVA data- 
base connectivity based application. 

15. An information handling system, comprising: 

a library, containing a plurality of database identities; 
a protected database, wherein user information must be 

provided to access said protected database; 
means for receiving a request from a user for content from 

said protected database; 
means for retrieving a particular database identity from 

said library, wherein said particular database identity 

corresponds to the user; 
means for inserting the particular database identity into 

the request; 

means for retrieving said requested content from said 
database; and 

means for sending said requested content to a requesting 
client. 

16. The information handling system as recited in claim 
15, wherein the retrieved database identity comprises a user 
ID. 

17. The information handling system as recited in claim 
15, wherein the retrieved database identity comprises a 
password. 



20 



30 
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18. The information handling system as recited in claim 
15, wherein said retrieving step and said inserting step is 
performed by a global sign-on database interface dynamic 
link library. 

19. The information handling system as recited in claim 
15, further comprising: 

responsive to a determination that user identification 
information is not necessary to retrieve said content, 
forwarding said request to said database unmodified. 

20. An information handling system, comprising: 

a library, containing a plurality of database identities; 
a protected database, wherein user information must be 

provided to access said protected database; 
means for receiving a request from a user for content from 

said protected database; 
means for retrieving a particular database identity from 

said library, wherein said particular database identity 

corresponds to the user; and 
means for inserting the particular database identity into 

the request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is an open data- 
base connectivity based application. 

21. An information handling system, comprising: 

a library, containing a plurality of database identities; 
a protected database, wherein user information must be 

provided to access said protected database; 
means for receiving a request from a user for content from 

said protected database; 
means for retrieving a particular database identity from 

said library, wherein said particular database identity 

corresponds to the user; and 
means for inserting the particular database identity into 

the request; 

wherein said request is received from a requesting appli- 
cation and said requesting application is a JAVA data- 
base connectivity based application. 
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